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SECTION  I 

THE  INTEROPERABILITY  IMPERATIVE 

Developmental  planning  for  the  military  use 
of  space  needs  to  be  underpinned  by  a  comprehensive 
interoperability  program.  Such  a  program  is  needed 
now  to  harness  rapid  technological  change  and  meet 
future  defense  objectives  in  a  cost-effective  way. 
The  program  should  be  joint  in  nature,  and  broad 
enough  to  encompass  the  needs  of  multiple  Services, 
Agencies  and  Departments.  The  National  Test  Bed 
can  serve  as  its  starting  point. 

Scope  of  the  Problem.  National  security 
increasingly  depends  on  the  development  and  use  of 
complex,  interconnected  systems  which  cooperate  to 
a  high  degree  to  support  multiple  missions.  This 
trend  has  been  evident  in  tactical  systems  for  many 
years  and  is  becoming  increasingly  important  for 
space  systems.  The  notion  that  we  can  **grow" 
command,  control,  communications  and  intelligence 
(C3I)  with  each  individual  space  system  was 
appropriate  when  those  systems  were  designed  to 
meet  limited  objectives.  The  Strategic  Defense 
Initiative  and  future  operational  concepts  implied 
by  the  National  Aerospace  Plane  and  hypersonic 
boost-glide  vehicle  compel  a  major  re-thinking  of 
the  approach  to  developing  system  requirements  and 
maintaining  associated  space  system  interfaces.  A 
much  more  comprehensive  and  systematic  approach  to 
obtaining  C3I  mission  requirements  and  inter¬ 
operability  is  needed  to  assure  communication  and 
data  access  across  families  of  systems  developed 
by  a  range  of  organizations,  and  supporting  comple¬ 
mentary  but  dissimilar  missions  across  the  spectrum 
of  conflict.  As  the  number  of  interface  opportu¬ 
nities  for  military  space  systems  grows,  and  as 
the  systems  themselves  become  more  complex,  it  will 
become  difficult  to  directly  test  their  performance 
over  the  entire  range  of  intended  operation.  Simu¬ 
lation  will  become  an  increasingly  important  tool, 
and  interface  specifications  will  be  critical  to 
achieving  a  desired  level  of  performance  and 
interoperability . 

Interoperability  among  space  systems  will  help 
improve  capability,  reduce  costs,  and  provide  a 
clear  path  for  technology  insertion.  Just  as 
Reduced  Instruction  Set  Computers  run  faster  by 
reducing  the  variety  of  intrinsic  operations, 
parsing  engines  which  generate  and  interpret 
messages  can  be  made  simple,  efficient,  and 
"standard"  by  adopting  interface  design  standards 
which  incorporate  a  minimum  number  of  rules, 
message  types  and  data  codes.  Simplified,  stand¬ 
ard  interfaces  will  be  easier  to  manage  and  will 
allow  new  systems,  capable  of  cooperating  with 
other  systems,  to  be  inserted  quickly  to  perform 
new  missions. 

Interoperability,  however,  will  not  be  with¬ 
out  risks  and  challenges  which  are  programmatic, 
fiscal,  and  technical  in  nature.  A  successful 


interoperability  program  must  have: 

®  Clear  leadership,  lines  of  authority,  and 
designated  advocates. 

®  Continued  funding  and  direction. 

°  A  process  for  developing  and  maintaining 
design  goals  and  technical  standards. 

°  A  process  for  certifying  that  systems 
comply  with  interfaces,  and  an  associated  process 
for  arbitrating  disputes  over  interface  compliance. 

°  A  process  for  systematically  determining 
how  proposed  changes  to  interface  standards  will 
impact  on  systems. 

Interoperability  programs  are  not  new  in  DoD. 
The  Congressionally-mandated  program  of  Joint  Task 
Force  interoperability  provides  an  excellent  model. 
We  do  not  need  to  reinvent  the  process,  but  only 
apply  lessons  learned.  One  such  lesson  is  the 
need  for  cooperation  among  Services  and  Agencies. 

The  Need  for  a  Joint  Approach.  Interopera¬ 
bility  is  inherently  a  joint  process,  and  needs 
to  be  managed  by  a  joint  program.  Standards  can¬ 
not  be  determined  by  a  single  Service  or  Agency 
since  they  impact  on  the  cost,  schedule,  and 
evolutionary  potential  of  programs  belonging  to 
multiple  Services  and  Agencies.  Moreover,  serious 
interoperability  programs  require  full-time 
management  and  extensive  coordination  efforts  by 
teams  of  technically-oriented  people.  Since 
interoperability  benefits  a  range  of  users,  it  is 
appropriate  that  participating  Services  and 
Agencies  each  contribute  technical  manpower  to  the 
efforts.  Standards,  then,  must  be  developed  and 
maintained  through  broad  participation  and  a 
concensus  process.  Once  implemented,  standards 
must  be  strictly  enforced.  This  does  not  mean 
that  standards  cannot  change  or  evolve;  it  means 
they  cannot  be  modified  unilaterally  by  a  program  ^ 
without  regard  to  the  potential  impact  on  other 
cooperating  systems.  The  proper  focus  for  an 
interoperability  program  in  on  definitions, 
messages,  and  procedures. 

Standard  Messages.  Interoperable  messages 
are  central  to  interface  design  standards.  They 
provide  a  context  for  and  give  meaning  to  trans¬ 
mitted  data.  Messages  can  be  character-,  voice-, 
or  bit-oriented,  and  their  structure  and  content 
can  be  completely  specified  by  a  formal  design 
language.  (Ada  Process  Description  Language  is 
one  example.)  Rules  for  message  transmission 
can  also  be  formally  specified,  and  channels  of 
communications  over  which  the  messages  flow  can 
be  rigorously  defined.  The  goal  of  an  inter¬ 
operability  program  should  be  to  get  the  right 
messages  to  the  right  systems  (people  or  machines) , 
at  the  right  time,  over  the  right  channels,  using 
the  right  procedures. 

Standard  Tools  and  Metrics.  An  inter¬ 
operability  program  must  be  supported  by  standard 
tools  and  metrics,  which  include: 

®  Systems,  procedures,  and  criteria  for 
evaluating  interoperability  standards  and  certify¬ 
ing  compliance . 

®  A  central  interoperability  database  contain¬ 
ing  existing  and  developmental  standards. 

®  Another  data  base  containing  inter¬ 
operability  test  plans,  procedures,  raw  data,  and 
evaluated  results. 

®  A  status-tracking  system  for  proposed 
interface  changes. 

Many  of  the  tools  needed  to  support  a  space 
interoperability  program  will  soon  be  in  place  as 
part  of  the  National  Test  Bed  (NTB)  program,  which 
will  link  major  SDI  research  centers  in  a  nation¬ 


wide  simulation  network  focused  on  strategic 
defense.  This  fact  suggests  a  cost-effective  inter¬ 
operability  approach. 

SECTION  II 
APPROACH 

Build  a  Limited  Initial  Program  Based  on 
Existing  Assets  and  Organizations.  SDI  is  a 
challenging  subset  of  the  space  systems  inter¬ 
operability  problem.  A  larger,  more  encompassing 
program  could  easily  grow  from  this  seed.  The 
National  Test  Bed  Joint  Program  Office  has  the 
charter,  organization,  and  a  growing  set  of  tools 
to  address  SDI  interoperability.  When  developed, 
the  capability  will  leverage  the  assets  of  test 
ranges,  laboratories,  and  research  centers  to 
focus  on  the  technical  feasibility  of  SDI.  It  will 
use  simulations  to  assess  the  performance  of 
interacting  systems  over  a  broad  range  of  opera¬ 
tional  environments  and  scenarios.  A  common 
simulation  framework  will  also  be  developed  to 
allow  engineering  models  of  SDI  elements  to  be 
evaluated  within  the  context  of  the  end-to-end, 
layered  Strategic  Defense  System.  The  NTB  must, 
of  necessity,  evolve  in  partnership  with  a  family 
of  participating  organizations  oriented  toward 
the  practical,  military  use  of  space. 

Document  What  Exists.  The  first  step  in 
establishing  an  interoperability  program  is  to 
catalog  the  existing  models,  tools,  interface 
specifications  and  operational  framework.  These 
configuration  items  represent  a  foundation  on 
which  new  systems  may  be  built.  Users  and  opera¬ 
tors  of  space  systems  will  have  a  vital  hand  in 
this  process. 

Define,  Test  and  Implement  Standards.  The 
next  step  is  to  propose  a  set  of  interoperability 
standards  which  meet  the  needs  of  systems  now  being 
planned  or  developed.  The  development  of  such 
standards  will  require  community  participation. 
Proposed  standards  will  be  tested  and  evaluated 
against  models  of  the  evolving  systems,  or  against 
man-in-the-loop/hardware-in-the-loop  experiments . 
Interface  design  standards  which  test  successfully 
and  are  adopted  should  be  incorporated  into  those 
systems  whose  design  baselines  can  accommodate 
them.  For  those  systems  in  production,  a  case-by¬ 
case  determination  should  be  made  to  decide  if 
increased  mission  capability,  measured  against 
the  cost  of  system  modification,  warrants  a  retro¬ 
fit  . 

Define  Future  Extensions  and  Growth  Paths.  A 
space  interoperability  program  must  be  future- 
oriented  of  necessity,  and  must  develop  growth 
paths  for  the  evolution  of  more  complex  and  capable 
systems.  Determination  of  future  operational 
requirements  is  critical  to  defining  such  growth 
paths.  For  this  reason,  Office  of  the  Joint  Chiefs 
of  Staff  (OJCS)  involvement  will  be  as  important 
for  the  interoperability  of  space  systems  as  it  is 
for  tactical  systems. 

Test  and  Evaluate  Interoperability  Standards 
in  Parallel  with  SDI  Simulations  and  Experiments. 
Using  a  philosophy  of  "build  a  little,  test  a 
little,"  we  can  start  building  into  our  test  plans 
for  SDI  the  evaluation  of  interface  standards. 
Initially  we  may  find  a  diverse  set  of  interface 
approaches.  By  systematically  analyzing  these 
approaches,  we  expect  to  converge  on  the  most 
promising  solutions  which  offer  the  widest  benefit. 

A  system  life  cycle  analysis  should  be 
accomplished  for  interface  design  standards  just 


as  with  any  other  developing  "system."  Such 
analysis  should  include,  but  not  necessarily  be 
limited  to,  sensitivity  analysis,  stability 
analysis,  compatibility  analysis,  utility  analysis 
and  state-of-the  art  analysis. 

Sensitivity  analysis  looks  at  important 
parameters  of  the  interface  design  standard,  and 
varies  them  in  turn  to  determine  the  effect  on 
end-to-end  simulation  model  performance.  Para¬ 
meters  which  are  shown  to  have  little  or  no  effect 
on  the  systems  and  subsystems  could  be  treated  as 
constants,  and  the  model  simplified  accordingly. 
Those  showing  large  sensitivities  need  to  be 
examined  in  greater  detail  since  these  affect 
system  performance  the  most. 

Stability  analysis  tests  the  interface  stand¬ 
ards  for  any  tendencies  to  produce  instabilities 
under  various  operating  conditions.  These  tests 
are  especially  important  for  large  constellations 
of  complex,  interacting  systems,  where  failure 
modes  may  be  difficult  to  forsee. 

Compatibility  analysis  evaluates  the  ability 
of  systems  to  exchange  information.  System 
parameters  and  models  should  be  examined  to  make 
certain  that  interface  conditions  and  system 
constraints  are  not  being  violated.  Ideally,  this 
analysis  should  include  an  examination  of  inter¬ 
dependencies  of  system  parameters  on  lower-level 
(Section  IV)  interface  parameters. 

Utility/interoperability  analysis  addresses 
the  value  of  the  interface  standard.  For  example, 
the  value  of  a  message  is  related  to  its  speed  of 
transmission,  syntactic  correctness,  information 
content,  and  information  accuracy  (measured  against 
objective  reality).  The  value  of  message  "strings" 
(sequences  of  messages,  triggered  by  interface 
operating  procedures)  could  be  determined  by  how 
well  they  comply  with  interface  rules  and  satisfy 
information  demands  of  cooperating  systems. 

State-of-the-art  analysis  determines  how  well 
technology  can  support  new  interface  design 
requirements  and  indicates  potential  problem  (risk) 
areas  in  technology,  cost  or  time. 

Interface  design  standards  may  also  be 
analyzed  in  terms  of  the  usual  "ilities"  (relia¬ 
bility,  maintainability,  availability,  security, 
etc.),  as  in  other  systems. 

SECTION  III 

THE  INTEROPERABILITY  PROCESS 

Interface  Change  Proposals.  An  interopera¬ 
bility  program  must  establish  procedures  for 
controlling  interface  definitions.  One  such 
procedure  is  the  Interface  Change  Proposal  (ICP) . 

An  ICP  may  be  submitted  by  any  participating 
Government  organization.  The  development  of  a  new 
system  or  the  desire  to  improve  interface  flexi¬ 
bility,  performance  or  security  could  justify 
submission  of  an  ICP.  Such  proposals  would  include 
a  concise  description  of  an  interface  "problem," 
analysis  of  the  problem  justifying  a  change  to  the 
interface,  a  description  of  the  proposed  modifi¬ 
cation,  and  an  initial  impact  statement.  The 
Interface  Change  Proposal  would  be  submitted  for 
review  by  all  participating  organizations  to 
determine  the  ramifications  of  the  change. 

Technical  Assessment.  The  purpose  of  a 
technical  assessment  is  to  consider  Interface 
Change  Proposals  submitted  by  participating 
organizations.  Based  on  technical  review,  and 
perhaps  supported  by  test  results,  formal  panel 
recommendations  and  an  impact  analysis  are  drawn 


up,  which  may  include  minority  views. 

Programmatic  Assessment.  The  purpose  of 
programmatic  assessment  is  to  review  analysis 
and  recommendations  based  on  the  technical  assess¬ 
ment,  and  vote  on  whether  or  not  to  implement 
Interface  Change  Proposals.  Recommendations  are 
forwarded  to  the  interface  authority. 

Interface  Authority.  The  Joint  Interface 
Authority  is  the  keeper  of  the  standard,  and  is 
the  "court  of  last  resort"  for  minority  opinions. 

He  either  directs  implementation  of  the  interface 
modification,  or  he  does  not. 

SECTION  IV 
PRODUCTS 

Interoperability  Concept  in  Perspective. 
Interoperability  is  the  ability  of  systems  to  work 
together  to  perform  a  mission.  To  be  useful,  this 
abstract  concept  must  be  embodied  in  interopera¬ 
bility  products  used  for  system  design.  Such 
products  include  an  interface  architecture,  inter¬ 
face  concept,  interface  operating  procedures  for 
passing  messages,  message  formats,  definition  and 
specifications  for  communications  links  and  net¬ 
works.  A  wide  variety  of  tasks  need  to  be  success¬ 
fully  accomplished  prior  to  developing  these 
interoperability  products,  however.  For  example, 
analyses  are  required  to: 

®  Determine  which  systems  must  interact  in  the 
variety  of  military  missions  to  be  performed. 

°  Determine  the  types  of  information  that  may 
be  exchanged  among  the  groups  of  systems  in  support 
of  their  mission  roles. 

°  Identify  individual  system  communications 
capabilities  sufficient  for  establishing  interface 
links  with  other  participating  systems. 

**  Determine  the  message  loading  and  timeliness 
requirements  for  each  system.  This  is  necessary 
to  ensure  that  the  types  of  communications,  in  their 
deployment  configuration,  are  suitable  for  the 
expected  types  of  use . 

°  Develop  an  interoperability  philosophy  that 
will  be  flexible  enough  to  permit  changes  in 
system  roles  and  capabilities  without  imposing 
excessive  cost  penalties  (on  systems  that  have  been 
previously  developed)  or  reducing  overall  system 
effectiviness. 

One  useful  frame  of  reference  for  considering 
interoperability  is  the  International  Standards 
Organization  (ISO)  Open  System  Interconnect  model. 
This  model  defines  seven  architectural  layers  for 
interactive  networks. 

®  Layer  1  —  Physical  control 

®  Layer  2  —  Link  control 

®  Layer  3  —  Network  control 

®  Layer  4  —  Transport  end-to-end  control 

®  Layer  5  —  Session  control 

®  Layer  6  —  Presentation  control 

®  Layer  7  —  Process  control  (Applications) 

In  programs  such  as  JINTACCS  and  TACS/TADS, 
interoperability  testing  typically  begins  with 
compatibility  testing  and  proceeds  to  an  evaluation 
of  the  utility  of  information  and  procedures. 
Following  successful  "laboratory"  testing,  the 
interfaces  are  "field  tested."  Systems  are  termed 
’compatible*  if  they  can  *talk*  to  one  another 
(exchange  data).  In  terms  of  the  ISO  model,  this 
capability  corresponds  to  layers  1-4.  Interopera- 


bility,  which  encompassess  compatibility,  is 
defined  as  the  ability  to  use  the  communicated 
data.  Thus,  interoperability  includes  ISO  layers 
1--7. 

The  development  of  interoperability  standards 
can  be  made  manageable  by  decomposing  the  problem 
into  smaller,  logically  consistent,  and  testable 
mission  segments.  For  example,  the  JINTACCS 
program,  which  deals  with  interoperability  within 
the  Joint  Tast  Force,  initially  defined  the 
segments  as  Intelligence,  Air  Operations, 

Operations  Control,  Maritime,  and  Fire  Support. 

A  program  for  interoperable  space  systems  might 
use  a  different  mission-oriented  break-down.  One 
possible  scheme  follows,  based  in  part  on  the 
Functional  Decomposition  developed  by  the  SDI  BM/ 

C3  Working  Group  for  Standards  (Sept,  1986): 

®  Launch,  Maneuver,  Rendezvous,  Docking  and 
Recovery 

®  Health  and  Maintenance 
®  Command  and  Control 
**  Battle  Management 
®  Fire /Weapon  Control 
“  Surveillance 
®  Communications 
®  Computing  and  Simulation 
®  Experiments 
®  Exercise  Control 

Layered,  Evolutionary  Interface  Architecture. 
Space  missions  involving  multiple  Services  and 
Agencies  will  ideally  have  architect-engineers 
responsible  for  developing  and  maintaining 
architectural  configurations  and  associated 
interfaces  which  meet  the  mission  goals.  Interface 
architectures  should  be  layered  for  the  following 
reasons : 

*  Layering  isolates  mission  functionality 
from  the  effects  of  system  changes.  For  example, 
the  upgrade  of  a  communications  link  need  not 
require  a  change  in  battle  management  applications 
program  if  the  messages  which  drive  those  programs 
are  not  changed. 

®  Modularization  by  means  of  layering 
simplifies  the  overall  design. 

®  Different  layers  can  be  assigned  to 
different  design  teams  and  different  standards 
committees. 

®  The  relationship  between  the  different 
control  functions  can  be  better  understood  when 
they  are  split  into  layers.  This  is  especially 
true  of  control  actions  which  occur  sequentially 
in  time  from  layer  to  layer. 

®  Common  lower  level  services  may  be  shared 
by  different  higher  level  users. 

®  Functions,  especially  at  lower  layers,  may 
be  removed  from  software  and  built  into  hardware 
or  microcode. 

®  • Plug-compatible'  connections  are  easier 
to  define. 

There  are  a  few  disadvantages  to  layered 
architectures.  These  Include  the  following: 

*  The  total  overhead  Is  somewhat  higher. 

*  The  communicating  machines  may  have  to 
use  certain  functions  which  they  could  do  without. 

®  To  make  each  layer  useable  by  Itself,  there 
Is  some  small  duplication  of  function  between  the 
layers . 

®  As  technology  changes  (e.g.,  as  crypto¬ 
graphy  and  compaction  chips  become  available. 


or  as  the  functions  can  be  built  onto  HDLC  chips) 
the  functions  may  not  be  in  the  most  cost-effective 
layer. 

In  general,  the  advantages  of  layered  archit¬ 
ectures  are  great,  and  the  disadvantages  are 
slight.  A  layered  architecture  can  serve  as  the 
basis  for  evolutionary  change,  and  defines  the 
purpose  and  structure  of  system  interfaces. 

Technical  Interface  Concept.  The  Technical 
Interface  Concept  (TIC)  documents  interface  require¬ 
ments  from  a  "user  system"  point  of  view,  specify¬ 
ing  interface  opportunities  among  systems,  and  the 
type  of  information  that  must  be  exchanged.  From 
this  compilation  in  the  TIC,  an  initial  assess¬ 
ment  can  be  made  by  the  development  planner  as  to 
which  systems  or  activities  will  be  impacted  by 
the  introduction  of  a  new  system.  The  needed 
categories  of  information  for  the  proposed  system 
may  be  determined  in  relation  to  operational 
requirements. 

Technical  Interface  Operating  Procedures 
(TIOP) .  Such  procedures  represent  a  comprehensive 
description  of  rules  for  sending  and  receiving 
messages.  They  describe  the  conditions  which 
"trigger"  a  message  transmission,  the  rules  for 
determining  addressees,  and  rules  for  selecting 
transmission  channels  and  precedence.  The 
application  of  such  rules  in  message-driven  systems 
produces  time-ordered  message  "strings,"  in  which 
messages  spawn  other  messages.  The  validity  of 
an  observed  message  string  can  be  evaluated  by 
comparing  it  against  the  TIOP. 

Technical  Interface  Design  Plan.  The  TIDP 
catalogs  the  interoperable  message  and  defines 
their  structure.  Standard  message  formats  specify 
the  organization  and  arrangement  of  the  data  fields 
in  messages  including  address,  control,  and  other 
system  requirements,  as  well  as  the  necessary 
information  itself.  The  utility  of  the  message 
format  (which  is  distinct  from  the  utility  of  the 
information  content)  is  partially  determined  by  how 
well  the  message  conveys  critical  information,  if 
and  when  such  information  is  available - 

Message  formats  may  be  either  fixed  or  vari¬ 
able.  Initial  attempts  at  automated  information 
exchange  have  involved  the  use  of  fixed  format 
binary  coded  messages,  such  as  the  Tactical  Auto¬ 
mated  Digital  Information  Links  (TADILs) .  Optimal 
use  of  this  technique  is  only  achieved  when  applied 
to  specific  applications  using  well-defined  and 
relatively  unchanging  messages. 

One  certainty  in  the  evolution  of  C3I  systems 
is  that  message  modification  will  be  an  ongoing 
process.  In  addition,  as  the  number  of  data  links 
employing  different  basic  message  lengths  (number 
of  bits  per  frame)  increases,  it  becomes  increasing¬ 
ly  difficult  to  define  a  common  set  of  messages  that 
can  be  exchanged  (to  provide  interoperability) 
among  a  group  of  systems  using  a  variety  of  these 
links.  In  summary,  fixed  format  messages  are 
limited  in  their  ability  to  provide  interoperabili¬ 
ty  among  C3I  systems - 

Generalized  data  transfer  mechanisms  using 
variable-format  structured  messages  avoid  the 
limitations  of  fixed  formatting,  and  can  treat 
fixed-format  messages  as  a  special  case  of  a  more 
generalized  interface  "language."  A  generalized 
data  transfer  mechanism  can  be  thought  of  as 
providing  a  buffer  between  a  message  processor's 
application  software  and  its  digital  data  link 
protocol  software  (or  firmware  or  hardware).  A 
transmitted  message  (received  from  an  applications 
program)  would  be  translated  from  its  system- 
unique  represenation  to  a  normalized  bit  or  byte 


stream  identical  in  all  implementations  of  the 
same  message.  This  stream  of  data  would  then  be  ^ 
passed  on  to  whatever  mechanisms  are  responsible 
for  encryption  and  adding  data  link  protocols; 
following  transmission,  the  process  would  then  be 
reversed  at  the  point  of  message  receipt.  In  this 
way,  interoperability  is  achieved  because  of  the 
agreement  in  the  appearance  of  the  bit  or  byte 
stream;  digital  data  link  transparency  is  achieved 
because  all  such  processing  is  carried  on  locally 
within  a  stream  prior  to  creating  the  normalized 
data  stream.  Generalized  data  transfer  also  solves 
the  problem  of  data  base  incompatibility  by  using 
interoperable  messages  as  a  common  query  language. 
The  rules  used  to  define  the  translation  from 
local  message  forms  to  the  common  data  stream 
representation  can  be  described  by  a  formal  process 
description  language.  Such  a  language  could 
describe  character-oriented  messages.  In  addition, 
language  features  could  be  added  to  accommodate  the 
inevitable  changes  in  message  types  and  contents 
that  are  the  result  of  an  evolving  C3I  architecture. 

Message  Element  Dictionary .  An  exhaus t ive 
catalog  describing  the  format  of  fields  contained 
in  messages,  and  specifying  the  range  and  meaning 
of  data  item  codes  which  can  populate  each  field. 

The  fields  and  their  associated  codes  represent  the 
smallest  units  of  information  meaningful  to  the 
mission.  They  are  the  lexical  "atoms'*  which  may  be 
arranged  and  aggregated  within  messages,  and  their 
exact  form  and  meaning  must  be  standard  across  all 
cooperating  systems. 

Table  of  Data  Item  Codes.  An  exhaustive 
list  of  approved  data  item  codes  which  can  populate 
message  fields. 

Table  of  Algorithms  and  Equations.  Standard 
algorithms  and  equations  used  to  compute  mission- 
related  or  communications-related  information  used 
by  more  than  one  system. 

Table  of  Physical  and  Mathematical  Constants. 
Authoritative  List  of  physical  and  mathematical 
constants,  to  be  used  by  all  cooperating  space 
systems. 

Communications  Channels  Specifications.  The 
communications  channel  specifications  include 
functional  details  of  the  physical,  link,  network, 
and  transport  layers;  channel  capacity;  expected 
bit  error  rates;  and  characterization  of  link, 
network  and  transport  delays. 

Interoperability  Master  Plan.  Time-phased 
plan  for  approving,  introducing,  and  upgrading 
interface  design  standards.  The  plan  should 
specify  the  systems  which  will  require  the  stand¬ 
ards,  and  the  organizations  responsible  for  main¬ 
taining  them. 

The  interoperability  process  must  generate 
interoperability  products  within  the  context  of  a 
management  structure.  The  next  section  suggests 
an  organizational  approach  which  encompasses  all 
participating  organizations,  and  provides  a  bridge 
between  operational  and  developmental  planning. 

SECTION  V 

ORGANIZING  FOR  INTEROPERABILITY 

The  Tactical  Interoperability  Paradigm.  The 
program  for  achieving  Joint  Interoperability 
Tactical  Command  and  Control  Systems  gives  the 
operational  community  responsibility  for  developing 
and  coordinating  requirements.  Within  the  Air 
Force,  Tactical  Air  Command  is  the  single  coordi¬ 
nating  authority  for  interoperability  requirements 
and  standards,  and  executes  a  Program  Management 


Directive  which  provides  direction  and  funding. 

ESD  manages  RDT&E  funding  for  the  program,  and 
provides  MITRE  support.  Other  participating 
Services  and  Agencies  have  adopted  a  similar  opera¬ 
tionally-oriented  approach.  Each  Service/Agency 
coordinating  authority  has  one  vote  in  a  joint 
forum  which  recommends  interface  design  standards 
to  a  joint  interface  authority.  The  joint  inter¬ 
face  authority  oversees  both  a  joint  program  office 
which  acts  as  architect-engineer  for  interface 
standards,  and  a  joint  test  activity  responsible 
for  verifying  the  interface  design  by  conducting 
tests  within  a  distributed  joint  testbed.  When 
the  joint  interface  authority  determines  that 
interface  design  standards  have  been  verified 
through  laboratory  testing,  the  standards  are 
turned  over  to  a  Unified  Command  for  field  testing 
and  implementation.  Once  approved  for  implement¬ 
ation,  standards  are  incorporated  into  JCS  publi¬ 
cations. 

The  organizational  structure  and  relationships 
supporting  tactical  interoperability  accommodate 
institutional  and  legal  constraints  on  research 
and  development  while  meeting  the  needs  of  the 
tactical  forces.  Leadership  by  the  operational 
community  in  requirements  development  ensures  that 
emerging  interoperability  standards  are  responsive 
to  current  and  future  mission  concepts.  Product 
division  managment  of  RDT&E  funding  and  FCRC  assets 
complies  with  Service  policy.  Joint  program 
office  management  of  architecture-engineering 
activities  and  testbed  operation  places  responsi¬ 
bility  for  technical  development  within  proper  R&D 
channels,  and  assures  a  fair  representat j.on  of 
Service/Agency  views.  Unified  Command  testing  of 
the  standards  under  field  conditions  ensures  that 
they  are  workable,  and  incorporation  of  standards 
into  JCS  publications  ensures  compliance  by  system 
developers. 

Organizing  for  Space  Interoperability.  The 
same  institutional  sensitivies  which  apply  to 
developing  interoperable  standards  for  tactical 
systems  also  apply  to  space  systems.  Each  partici¬ 
pating  Service /Agency  should  have  a  single, 
operationally-oriented  focal  point  for  coordinating 
interoperability  requirements.  Air  Force  Space 
Command  would  be  a  logical  choice  as  the  Air  Force 
focal  point.  The  National  Test  Bed  is  the  logical 
place  to  conduct  laboratory  testing  of  interface 
design  standards.  The  SDIO,  because  it  is  an  OSD 
organization  with  broad  responsibility  for  develop¬ 
ing  and  integrating  a  variety  of  space-related 
systems,  is  the  logical  choice  as  the  joint  inter¬ 
face  authority.  U.S  Space  Command  should  assume 
responsibility  for  field  testing  and  eventual 
implementation  of  standards. 

Interface  design  standards  for  a  Strategic 
Defense  System  will  be  developed  by  the  SDIO  and 
tested  in  the  National  Test  Bed  even  if  no  broader 
interoperability  program  is  created.  However,  in 
this  limited  subset  of  the  space  interoperability 
problem  there  is  a  need  for  a  systematic  process 
which  coordinates  and  prioritizes  operational 
requirements  and  funnels  them  Into  the  technical 
design  of  interfaces.  Establishing  a  space  inter¬ 
operability  office  within  Air  Force  Space  Command 
will  create  such  a  process  for  the  Air  Force,  and 
could  prompt  other  Services  and  Agencies  to  follow 
suite. 


f 


SECTION  VI 
RECOMMENDATIONS 


°  Endorse: 

-  Space  systems  interoperability  program 

-  Suggested  interoperability  approach 

-  Need  for  well-defined  products,  process 

RATIONALE: 

-  Gain  additional  leverage  from  future  space 
applications 

-  Support  planned  evolution  of  complementary 
space  capabilities. 

-  Improve  mission  effectiveness 

-  Support  rapid  technology  insertion 

-  Lower  system  costs 

-  Provide  visibility  into  the  effects  of  change 

Establish  formal  Air  Force  Interoperability 
Program 

-  Provide  funding,  direction,  responsibility 

-  Air  Force  Space  Command  should  be  Service 
coordinating  authority 

-  Feed  requirements  for  interface  design  stand¬ 
ards  into  SDI  BM/C3  program  for  evaluation  in 
NTB 

RATIONALE: 

-  Creates  formal,  recognized  mechanism  for 
establishing  and  prioritizing  Air  Force 
interoperability  requirements 

-  Spurs  other  Services  to  adopt  similar  programs 

-  Builds  on  existing  SDI  infrastructure 

°  Obtain  top-level  management  agreements  needed 
for  broad-based  program 

-  Principals:  OSD,  OJCS,  NASA,  Army,  Navy,  DIA, 
NS A,  DARPA 

-  Observers:  NBS,DOE,  NATO 
RATIONALE: 

-  Creates  formal  mechanism  for  establishing  and 
prioritizing  National  interoperability  require¬ 
ments. 
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